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Mosc =inicor.putecs do not <liy tlnglrtsh in their 
architecture between addresses and other operands, with 
Che result chat operand size becomes a de facto limit 
on address size (and thus memory size). This has 
created serious problacs for many architectures when 
at tempting to build syszeas with large address space. 

It is possible, however, to make address size 
"invisible" to Che progracaer and independent of oper- 
and/word size. This is achieved by defining the archie 
ceccure to segregate addresses from other operands, 
and to coDper.sace for the cunber of storage words 
required to hold an address. 

In a system so designed, the assembly source code 
written by a programmer then becomes "independent" of 
the address size of the particular computer for which 
it is Intended; differences in address size becoming 
the concern of only the assembler. 

The implementation of this concept in a new mini- 
computer architecture is described. The necessary 
features in the architecture are identified, and the 
manner in which the assembler creacs addresses is des- 
cribed . 

The effects upon ease of programming of these fea- 
tures is considered, and the object code produced (from 
a single source code) for two systems with differenc 
address sires is analyzed. It is found chat the sample 
programs will be only 5X larger and 37. slower for a 
system with two- word addresses than for a system vich 
one-word addresses. 

I - IMTRODUCTION 

One of the cost difficult (and most recurrent) 
problems facing the minicomputer architect is that of 
sufficient address space. Addresses should be poten- 
tially large enough so that all of the data and pro- 
c _^ du E es for cost processes can be directly addressed 
without recourse to memory napping. Memory aapping/ 
management is not inherently undesirable , but its pri- 
mary purpose is to solve other problems than that of 
inadequate address size (Randall, 1963). Such large 
addresses, however, should not compromise the archi- 
tectural simplicity and minimal hardware cose which 
cha rac te rize the ndnicompuc er . 

A minicomputer Ls usually organized around a 
fixed, relatively small memory word size (typically 12 
to IS bits), and uses chat word size as a common con- 
trolling parameter throughout its architecture. Oper- 
an-J-i, instructions and addresses are all usually of 
that sane size. Frequently, both for reasons of cose, 
and for purposes of address r^nipulation , addresses 
and operands even share the sace operating registers. 

T * n - u ->* of such .in organization can be very cos e- 
e: receive , but has the serious deficiency that it 
creates a de facto linic on renory size, by requiring 
that addresses be no larger than operands. If memory 
wo cd/re^ liter size is 16 bits (a convnon size), for 
sr.ar-.o . rh*n ac« r^s jss ace constrained to a maxisium 
size of 65,536 words. 



This has proven to be a severe limitation in re- 
cent years, for both functional and economic reasons. 
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Tasks and applications have tended co expand in scope 
requiring additional memory; operating syscens and 
higher-level languages, while improving system func- 
tionality, have had a major impact on aenory size. 
Reduced memory costs have also fueled user require- 
ments for large memories: Memory costs decrease at the 
rate of 262 to 41Z per year; since users tend to buy 
constant dollar amounts of memory, it follows that the 
amount of .address space typically required doubles 
every 2-3 years (Bell, 1976) . 

A number of minicomputer architectures have 
accepted this de facto limit on memory size, and then 
been found wanting as the demand for larger memories 
increased . 

One example, is the Honeywell 116, 516/^16, 316, 
System 700, Level 6/06 series of minicomputers. Ori- 
ginally designed co support 16K (K-1024) words of mem- 
ory, this family has twice been expanded; the first 
time by an architectural modi: ication which increased 
address space to 32K words, the second by che addicion 
of a somewhat cumbersome bank-switching schece which 
Increased physical memory size co 64K words. 

A second example, of core recent origin, is the 
PDP-11 family of computers. Initial members of this 
family supported an address space of 56K bytes (entire- 
ly adequate in 1969, the year of their introduction) ; 
within two years it was four.d necessary co introduce 
memory management in order to meet the demand for 
larger physical memories (Bell, 19 76). 

II - ADDRESS SIZE Ii-rDEPEI'fuEMCZ 

When the architectural and design studies for a 
new minicomputer were begun at Honeywell Information 
Syscems £ years ago, it was clear fron che beginning 
chac chis was che development of not just or.e , but an 
entire family of computers. This meant chat the new 
architecture had to support not only the system with a 
large address base and elaborate operating systems, 
but also the small OE>i-oriented system where speed and 
miniaum program size were essential. Equally essen- 
tial, however, was the necessity noc co impair pro- 
gram cobility (the ability to transport programs from 
from nachines at one end of the family to machines 
at the other) . 

A particular goal of the study was to develop a 
method of dealing with addressing which would not be 
tied to word size, but be open-ended and consistent in 
all members of the family, and not icpair program 
mobility from one member of che family co another. 

The ^o_rd__3 ize (the number of bits of data repre- 
sented by the least significant bit of an address) had 
already been fixed acjijits. If this word size 
represented che largest address size, however, memory 
size would be limited to 6iK words; sufficient for 
present applications, but obviou>iy i-adequace for 
future needs. It was felt that to have a reasonable 
certainty of being able to satisfy aer.ory requiraments 
for the lift of the family, chat maximum memory size 
should be ac least 8 co 10 million words (implying an 
adcress size of at Zj Dies). However, addresses 

larger than 16 bits would then require 2 words of mem- 
ory to hold them, and take twice as long to Iced and 
store. Tne large-system user, running under an 
operating system, would not object co this burden, 
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since it would significantly reduce the amount of 
storage management and overlay activity --hich, of 
necessity, accenpanias a sir-all address space J • The 
-^mall-system, OEM us-er uouli be unwilling to incur 
this space/tine penalty, however, since his address 
space requirements are smaller, and his application is 
typically ciore cos t/perf orr.ance sensitive. 

Examination of the nature and usage of addresses 
reveals some interesting properties par- icularly in 
the ways in which they differ from other operands. 
All other operands are programmer visible, explicitly 
typed and sized; they are bits, bytes, words or multi- 
words, etc. The progra=mer is avare of the size of the 
itea being dealt with and uses this characteristic 
in manipulating it. Addresses, however, are primarily 
the concern of the assembler, and only of secondary 
interest to the programmer- They are the names of 
structures, arrays and program locations. The program- 
mer wants to be able to assign names as required, and 
t..en reference them as necessary, without getting 
immersed in address computation and manipulation. (It 
was the burden of such tasks that led to the develop- 
ment of assemblers in the first place.) To the pro- 
• grammar, address size is unimportant; as long as an 
address is 'big enough" the programmer doesn't really 
care. J 

Consideration of the differences between addresses 
and other operands led, in turn, to a concept which we 
refer to as address size independence; a philosophy of 
architecture in which the size of addresses is essen- 
tially invisible to the programmer at the level of 
assembler source code, and is only apparent at the 
object code level. 
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Fig 2 - Address r o macs 

Each system would receive object code containing addr 
ses suitable to its hardware, while the programmer. 

°^ T t C t n \*\ Ch * leVel ° f < he Sln * Le ^urce code from 
which both object codes are derived, vould deal with 
addresses as tags and identities, in a non-size-speci 
fashion. H 



This philosophy involves a 
concepts. 



number of interacting 



The first, control of address manipulation; a ca; 
ful limitation of the direct accessibility to the pro- 
grander of addresses as operands. Such natural opera- 
tions as loading, storing and certain types of addres- 
manipulation would be possible, while at the same tin! 
any usage or manipulation which would be cognizant of 
and sensitive to their size, would not be. 

The second, compensation for size at time of use 
defining address syllable functionality in such a way 
that any use of or reference to an address by. the pro- 
grammer which is sensitive, to address size will be 
compensated for by the hardware/firmware. (This per- 
mits such common operations as indirect addressing 
stepping through a string of addresses, or indexing ii 
an array of addresses.) 

The third, awareness of misuse; the detection, 
wherever possible, of address manipulations by the pre 
graomer which, although technically permissible, in 
fact represent, variant usage of the hardware, and mak* 
the program sensitive to address size. 

A fourth, assembler .sensitivity to address size; 
provision of a method whereby the assembler can be 
informed of the existence of addresses or address- 
sized icems in the specification of constants and off- 
sets and the creation of data st ruccures , so that the; 
items can be correctly processed into 1 or 2 words 
according co the size of the target systen. 

- It-tPLEMEKTATION (HARDWARE) 

' In order to achieve this desired automatic hand- 

ling or, and thus independence of address size from tt 
programmer's point of vi^, a number of soecial featu: 
were required in the hardware and the architecture. 

First, and perhaps r.osc significantly, the ra g li- 
t ers in the architecture are very carefully classifiec 
and separated on the basis of whether :hey contain 
addresses, or other, non-address, operands (see Fig. : 
Those containing addresses are restricted to the sever 
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base" registers, and the program counter. All ocher 
registers are classified as containing ocher operands 
(status and rode information, test result indicators, 
bits, bytes, words*. a.nd- emit ivords, etc.), ail of whose 
sizes and rorrjts are" very visible to the prograrmer. 
The size definition g£ _the 3 address-containing re gis- 
ters Is lef: open in the architecture deac ript io n*7 

speclrying or.iy cnat they are bejve en 16 T and 3 2 bits in 
lengthy ccr.caiti Integer . quantities with the ralige 
0 to 2 -1 (where n is the length) , and will be of dif- 
J ere n t_-S i z est n di fferenc configurations/family members. 
^ Address Registers"^ 
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Fig 3 - Systea Register Set 
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operations and svrnipu la tions available to the prog 
to those vhl=h ar* uddress-si- insensitive. Five 
codes are provided tor base register manipulation: 
u ° ad ' Store, Su-ap, Compare and .Load Address (a special 

mod 



t unction which gives the programmer the ability to m 
i-y base registers under control of the address syl- 
t aole or the instruction). An instruction is provid 
-or testing an address for null (o 9 ), in either a base 

^ r °^ memory. Two op codes are available for 
'od 2 ™?-^"^ nani P uLaci <>n. both Jumps. An eighth op 
- e, -ln k Jump, affects both the program counter and 



base register. 

So other op codes affect the address register- 
The shirt, logic, arithmetic and b it -ooera-ions av^i 
able for the other-operand registers are spaclficall 
not provided; they are all operand sire sensitive *L 
would require programmer awareness of address size. 

It Bight be pointed out here that 
of registers has yielded the fringe ber. 
registers and more opcodes than would h 
been expected in a 16-bit architecture, 
space wasted in the op code/register ty 
unnecessary and undesirable operations 
divides, shifts, etc. on address regist 
combinations thus saved are used for no 
specific to the other-operand registers 
instruction repertoire. 
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It is not sufficient, however, to control just 
the explicit manipulation of addresses by the program^ 
mer; it is also necessary to treat the problem of 
addresses encountered during address syllable resolution. 

Three types of address syllable resolution eviden- 
ced special problems when dealing with addresses in 
| B *™f/: Slobal addressing, in which the address is part 
or the instruction; indexing, when the array element 
being referenced is itself an address; and moving base 
register addressing (base, post- incremented and base 
pre-decremented) when the operand being stepped past 'is 
an adacess. All are sensitive to address size (1 word 
for n<16, 2 words for 16<n<32) and all are resolved by 
extending techniques already present in the architectu-e 
to include sensitivity to address size. 

In global addressing, the address of the operand 
is pare of the instruction; thus, in a SAF (Short 
Address Form) system, the instruction occupies two words 
while in a LAF (Long Address Fona) systea, the ins true- ' 
tion occupies three words. The architectural definition 
of program counter functionality was elastic enough 
to accomodate this difference. It had been defined as 
capable of automatically incrementing by an amount from 
one to six words to permit the use of multiword instruc- 
tions; it was simple and consistent to define it as also 
• sensitive to address size , incrementing by an extra word 
after t..e fetch of an instruction using global addres- 
sing in a LAF systea. 

It should be noted that the existence of new 
variable length instructions does not create untoward 
problems for either assecbler or programmer . All con- 
trol transfer instructions (Jumps and Branches) are 
formatted to explicitly identify their (alternative) 
destination. Mo implicit assumptions, such as the sk^ps 
performed by branches in some systems, exist as to 
destination to interfere with assembler generation of 
SAF or LAF code as appropriate. 

When indexing into an array of addresses, address 
size differences are compensated for by the already- 
present architectural feature of "indexing to the kernel". 
This Is a technique whereby all indexed memory references" 
are operand size sens i tive , au toma t ically aligning the 
index prior to the index addition so that the least 
significant bit of index value represents one "item" in 
the array (not necessarily one uorcj. Here again, only 
a minor extension was necessary to encocpass SAF/LAF 
differences. In a SAF system, no index realignment ia 
necessary; the least significant bit of the index 
represents one word. In a LAF system, the LS3 of the 
index represent; tu-o words, and the harcvare causes it 
to be left shifted 1 bit (doubled) prior to the index 
addition. This permits the compatible use of address 
pointers in both SAF and LAF configurations. 



The third type of addressing difficulty, that in- 
volving moving (pre-decremented or pos t-incremenced) 
base registers, was resolved as. In the other two, by. ex- 
tending already existing^ functional tiy so that it be- 
comes sensitive to. address size. The amount by which 
the base registers increment or decrement in this type 
of addressing was already variable, being whatever in- 
tegral number of words was appropriate to the size of 
the operand (a function of the op code). It was, again, 
very simple and consistent to extend this so that when 
the operand was an address, the size of the increment/ 
decrement was then sensitive to Che SAF/LAF configura- 
tion. 

Another class of problem relating to address size 
independence was chat of address overflow/underflow. 
Tocally unrelated to address size/word size disparities, 
overflow/underflow is a condition which occurs when 
address computation creates an address "below location 
zero" , or "above" the largest address which vill fit 
in an address register in a particular conf iguraion. 
An example of underflow would be to index by a value of 
-200 relative to a base address of 100; the resulting 
address (location "-100") cannot be represented in an 
address register (addresses have the range of 0<EA<2 n -l) , 
the borrow would be lost, and Che result appear to be a 
very large address (100 words below the largest address 
possible for the configuration). Similarly, overflow 
would be to index by +200 relative to a base address of 
65,436 in a system with 16-blc addresses; the resulting 
address (location "65,636") is too large to fit in a 
16-bit address register, the carry would be lost and ' 
the resulting address appear to be 100. (Note, however, 
that in a different system with larger address regis-' 
ters this computation would have been permissible and 
the resulting address legitimate.) 

Address overflow/underflow is clearly an area in 
which address size is visible to the programmer- Fur- 
thermore, there is no way to prevent the programmer from 
specifying address parameters which can cause it 
"(there would, in fact, be ascendency for too-clever pro- 
grammers to deliberately use this behavior to increase 
index/displacement range when hear the bottom or top 
of the address space). : 

It. was decided, therefore, to make address over-' 
flow/underflow illegal, testing for the appropriate' 
combination of sign and carry at the time of addition, ' 
and forcing a trap (an internal synchronous interrupt) 
if detected. This crap invokes the same software acti- 
vated by a reference to uninstalled memory (a "missing 
resource" trap), and allows the programmer to correct 
this (hopefully) inadvertent misuse. 

IV - IMPLEMENTATION (SOFTVARE) 

In the process of defining the handling of addres- 
ses by the hardware, it became clear that some compen- 
sation for address size would have :o be made in the 
syscem sofevare as well. Certain classes of operacions 
could neicher be compensated for nor prevented from 
occurring . 

A case in point was the explicit definition by che 
programmer of either an offsec or constant specifying 
some number of words and addresses, or the specifica- 
tion of a cenmon block or data structure containing 
addresses. In such cases, there is no way to preclude 
progracrcer cognizance of address existence. The pro- 
graraer nusc inform the assembler of the desired off- 
set size; the comTon block ?usc be large enough to hold 
che necessary data. 

Here again, however, we could distinguish between 
address existence and address size . A special internal 



value label was defined for the asseciler, called $AF 
The value of $AF is set by che asset* ler , I n accordance 
with the configuration of che target system. If f or a 
SAF (1 word address) system, then $AF~1 ; If for a LAF 
(2 word address) syscem, chen $AF<»2. - 

This label, $AF, can be used by the progra~ner 
wherever necessary when referring to addresses, in- 
order to specify number of words per address and thus 
distinguish SAF from LAF assembly as appropriate. 

Two examples will suffice to illustrate its util- 
ity: If it is desired to displace relacive to a base 
register by 23 items, where 18 of the iteas are words, 
and five are addresses, then the assembly language 
addressing statement would be: 

,$Bx.l8+5*$AF 

which would be assembled with a displacement of 23 for 
a SAF system, and 28 for a LAF system. This would be 
the general method for accessing into any non-homogeneous 
data array, such as a stack or paramecer table. 



Similarly, the reserve statement 

(LABEL) RESV 12*$AF,3 

intended to reserve space for 12 addresses at location 
(LABEL) , will reserve 12 words in a SAF system, but 
26 in a LAF. This technique allows the programmer to 
allocate space for address arrays In SAF/LAF indepen- 
dent fashion. 

V - RESULTS & EVALUATION 

The addition of the SAF label in the assembler was 
the last major element necessary to make address size 
independence a workable concept. 

Other, minor, changes were still required (such as 
specifying hardware dedicated memory locations in a 
manner which made them readily accessible In both SAF 
and t_AF) but these were not critical. The separate 
registers and op codes, the automatic compensation for 
address size, the address overflow/underflow detection,, 
and che $AF label were che basic elements supporcing 
address size independence. 

Two questions had to be answered, however. Had 
ease of programming been compromised In order to intro- 
duce this functionality? and how successful were these 
features in supporcing SAF /LAF independence and program 
mobility? 

Ease of programming is a dlf f iculc' property to 
evaluate and quantify, being to a large extent subjec- 
tive and programmer-dependant. In this case, where we 
were concerned primarily with second-order differences, 
it was doubly so. What was at issue was: how rescric- 
cive, how hard Co learn and how artificial in appear- 
ance, were the special features in the architecture 
which had been developed to support SAF/LAF independence. 
It was this "ease of programing" which had to be eval- 
uated . 

A significant insight into thi3 aspect of che 
archicecture was achieved by composing the list of guide- 
lines for programmers wricing SAF/LAF independenc code. 
It is obvious Chat the more complex and numerous such 
guidelines are, the less easy and natural Co program is 
the archicecture. In this case, the list of guidelines 
was short, simple and not r.a rkedly restrictive, and 
could even be considered as guidelines for "good pro- 
graming practice. They are largely concerned with 
awareness of the existence of addresses as compared to 
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othor operands, and have been found co be neither dif- 
ficult co Learn nor co follow (a summary of chese guide- 
lines will be found ^inj Appendix A) 1 . 

A second cesc of ease of programming was co exa- 
mine che coding' of che various benchmark programs, code 
kernels which exercise and cesc individual computer 
features, searching Cor strengths and deficiencies. 
Such bench-jrks are cocwon' in architecture evaluation 
(Fuller; 1977), and a sec of 10-15 such has been used 
foe this purpose at Honeywell for a nunber of years. 
Different benchmarks cesc different archlceccural fea- 
cures, from byce handling co argument passing, buc ic 
was noc specific, over: features chac were of inceresc 
in chis case, so much as an illustration of the pro- 
graming difficulties and anooalies which chey exhibited 
due to che SAF/LAF independence. 

Here again, it seemed we had been fairly success- 
ful in avoiding awkward functional situations. It was 
hard co idencify any specific case where the special 
SAF/LAF functionality (or progra-ming guidelines) cos C 
us either space or speed. As an example, consider che 
benchmark program, HIST (Histogram), designed to Cesc a 
computer's looping and comparison facilities. This 
subroutine tests an array of 1000 integers, ITABLE, 
whose address is procedural in the calling routine, 
and creates a histogram of their integer values (dis- 
carding all values less than zero and greater than 100) 
in an integer array, 0TA3LE, whose address is procedural 
in the subroutine and is returned to the calling routine 
in base register B2. The source code for this subrou- 
tine cine, togecher wich ics SAJ Assembly, is shown in 
Appendix B. 

Note chat there are only chree occurrences of . 
addresses in Chis coding, two* in the call (<HIST and 
< ITABLE) and one in the subroutine (<0TABLE) . Note 
also che use of the Link (B7) to get <ITABLE and step 
past ic at che same time '(at location 1007) , and che 
automatic stepping past of che Program Councer when 
using the occurrence of <0TABLE (ar location 1000). 
There' are no identifiable places in this subroutine 
where che features supporting address size independence 
-penalize, or even become noticeable co the programmer. 

/On the basis of: a) Consideration of the guide- 
lines for writing SAF/LAF independent code, and b) 
Examination of the coded beach mark programs used for 
evaluating che architecture, we were able to conclude 
thac SAF/LAF independence did noc s ignif icancly degrade 
ease of unders canding or programming in the architecture. 
This has subsequently been substantiated by the exper- 
ience of the large body of programmers now using chis 
machine; che general consensus being chac che one bar- 
rier to ease of programming in this system is its 
exceptionally rich instruction set and address syllable, 
not the concept of SAF/LAF* independence. 

The second question mentioned earlier , SAF/LAF 
independence and Program Mobility can probably besc be 
answered by considering che LAF Assembly of che bench- 
mark program, HIST, cited earlier (Appendix C) . 

As expected, che . differences becveen the SA? and* 
LAF asserts lies is minor, and of the type automatically 
compensaced for by the hardware. The number of words 
required for che subroucir.e has. increased from 17 co 13 
words (a 52 increase), and che number of memory cycles 
(for an ITABLE wich 100 incegers out of range) from 
8912 to 8915 (less Chan 0.1Z). 

W~nac is -.ore important than. size and speed, how- . 
ever, is Co note how easy ic is co write programs thac 
can assemble in eicher .-node; no special precautions 
vere taken in coding this benchmark to provide for LAF 
addressing; che use of che existing functionality did 



did thac automacically and wichouC problems. 

'Prior to coding che benchmark prosra^s, it had beer, 
estimated chat the object code for a LA? system would 
be '5 to 10 percent larger and ri:n 5 to 10* percent slower 
than that for a SAT system. This escir.acc has proven to 
be conservative; che coded benchmarks indicate chac 
typical size and speed differences are 5 percent and 3 
percent respectively (see Table 1) . 

X INCREASE SAF: LAF 

BENCHMARK 
FUNCTION 

ASCII co Hollerith Conversion 
BCD to Binary Conversion 
Unpack and Edit 
Co-rmuni cat ions Buffer Driver 
Hiscogram 

Memory co Memory Move 
Serial Byte Key Search- 
Tolerance Check 
Quicksort 
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9.6 


5.8 


1.1 


4.0 


.4 


.2 


7.0 


4.7 


0.1 


6.3 


1.0 


2.6 


2.4 


5.6 


2.5 


.8 


1.4 


12.0 


2.8 


4.7 



Average 

Table 1 - LAF Size/Speed Increase 

The differences between SAF and LAF are equally 
small in large segments of operational code. Consider 
the following two examples (both prograa modules from 
the Level 6 CC0S/BES software): 

The system execucive in CCOS/BES is a good example 
of a large (6000 word) program module with cany exter- 
nal references and absolute addresses yet che sire 
difference between SAF and LAF object programs for. this 
module is only 5.4Z 

The GC0S/BES Text Editor is aa example of a large 
(4000 word) program with almost no external references 
or absoluce addresses. For chis program, the LAF object 
code is only 20 words larger than the SAF (0.5Z). 

Less, exact information is available as to execution 
time differences between the two modes for system soft- 
ware. Measurements, of software systems performance are 
inconclusive, since ciost operational software cends co ■ 
be frequencly I/O bound, oasking che differences in 
program execution time caused by SAF/LAF distinctions. 
What, data is available, however, indicates that the 3Z, 
speed penalty observed for the benchmarks is equally 
valid for operational sofeware as well. 

A C SC'CVL E DC EM ENT 

The concept of address size independence is che . ' 
invention of no one individual, buc racher the synthesis 
of ideas and suggestions from many. ^\e' contributions 
of John Crandmatson, Richard Le=iay , ?ac rick Prange and 
Willlaa Woods are particularly acknowledged. 
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